This might not be necessary but it seemed like it could be useful to build a button with some base behavior and pass it to something else to add its own behavior, a little bit like DOM event bubbling. This seems like the right compose direction to me but I'm curious what anyone else things.

I love this! Maybe if you want we could also expose a more flexible variant like this?

onPress' :: forall c. (Aff Unit -> Aff Unit) -> ButtonModifier c
onPress' f = propsModifier \props -> props { onPress = f props.onPress }

Not sure if it would be useful though.

I like this pattern, thanks @arthurxavierx! These styles feel a lot safer bound to a specific component type.

The caveat here is that modifiers of type forall c. ButtonGroupModifier c can be applied to any component, so maybe this alternative is safer?

type ButtonGroupModifier c = forall r. PropsModifier (buttonGroupComponent :: c | r)

And for every component we have (textComponent :: c | r), (buttonComponent :: c | r), etc.

Ah, true. I wonder if PropsModifier should contain the (component :: c | props).. then it'd be as general as it is now by default so long as c is left open, but locked to a specific component as soon as you set c, and we wouldn't have the redundant XYZModifier types.

Related- I was also wondering if there was a better way to type loadingContent, it didn't fit into ButtonModifier because of the other prop constraints. It works as is, the inconsistent type aliases just seemed a little weird.

The XYZModifier types are also kind of a weird pattern to me. It's just duck typing actually, because we're saying that such and such modifiers apply to any component that has those props (and only to those), and it breaks in the case where a related component has different props (like with loadingContent).

I think that what we want is primarily a way of constraining modifiers to certain components in a hierarchy, it seems we don't have to care about the props like that, so maybe another way of doing it could be something like this?

type ButtonModifier props = forall c. IsButton c => PropsModifier (component :: c | props)

class IsButton c
instance IsButton Button
instance IsButton LinkButton

Not sure how type inference would be affected by that though…

Perhaps a phantom type like PropsModifier Button r as well? Going to merge this as is for now though, since it doesn't affect usage much.

Unfortunately PropsModifier cannot have a phantom type parameter because it's a type synonym, so that PropsModifier Button r and PropsModifier Text r would be the same type (unless, of course, that parameter were used in the definition of PropsModifier).

Ah right

This seems quite specific to the Button and ButtonGroup components. Maybe we should call it buttonShades or move it somewhere else?

Oh haha, I moved it here because it didn't seem buttons specific. Like part of the theme is all our current colors/hues, and this sort of expands each one into a wider range of related colors. I also wondered if it'd be better to move this function into the theme so it can be replaced.

Hm I see… I can see the use for hueDarker, hueDarkest, and hueDisabled, but maybe we should grab grey1andgrey2from the theme itself? We alredy haveblack1andblack2`.

(this is totally non-blocking btw, just pure nitpicking)

True. We should probably expand all the colors instead of just black if we can do it algorithmically, or leave the theme colors as-is and restrict button color to those predefined ones. The whole theme idea could use some work, like making it available to design and having more things use it so it doesn't look silly as values change, dark mode, etc.